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FOREWORD 


This  document  describes  the  beginnings  of  a  methodology  for  requirements 
specification  and  traceability  of  real-time,  large-scale,  complex  computer- 
intensive  systems.  The  method  Is  aimed  at  better  understanding  the  top-level 
system  requirements  and  how  they  relate  to  the  system  under  design. 

The  ability  to  formally  capture  and  understand  the  top-level 
requirements,  before  beginning  the  analysis  and  design  of  the  system.  Is 
critical  In  creating  systems  which  correctly  reflect  the  user's  needs  and  the 
avoidance  of  costly  redesign.  Being  able  to  formally  and  efficiently  relate 
the  requirements  to  the  system  design  and  Implementation,  through  traceability 
techniques.  Is  essential  to  guarantee  that  the  design  completely  meets  the 
requirements.  Traceability  also  Is  needed  to  properly  maintain  a  complex 
system. 

The  authors  would  like  to  thank  their  sponsor,  the  Office  of  Naval 
Technology,  especially  Cmdr.  Jane  Van  Fossen,  USN  Ret.,  and  Elizabeth  Wald. 

The  authors  would  also  like  to  thank  Phil  Hwang  and  all  who  provided  technical 
support  to  refine  this  report,  and  Adrien  Meskln  for  her  editorial  support. 


Approved  by : 

C.  A.  KALIVRETENOS ,  Deputy  Head 
Underwater  Systems  Department 
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ABSTRACT 


This  document  describes  the  beginnings  of  a  methodology  for  requirements 
specification  and  traceability  of  real-time,  large-scale,  complex  computer- 
intensive  systems.  The  method  is  aimed  at  better  understanding  the  top-level 
system  requirements  and  how  they  relate  to  the  system  under  design. 

The  methodology  will  cover  the  requirements  aspects  of  system  development  over 
the  entire  system  development  life  cycle,  beginning  with  the  specification  of 
the  requirements  and  tracing  those  requirements  to  the  design  and  final 
implementation. 
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CHAPTER  1 
INTRODUCTION 


The  purpose  of  this  document  is  to  provide  a  detailed  explanation  of  a 
Requirements  Specification  and  Traceability  (RESPECT)  methodology  which  is 
being  developed  under  the  Engineering  of  Complex  Systems  (ECS)  Block  program. 
The  methodology  will  cover  the  requirements  aspects  of  system  development  over 
the  entire  system  development  life  cycle,  beginning  with  the  specification  of 
the  requirements  and  tracing  those  requirements  to  the  design  and  final 
implementation . 


1.1  BACKGROUND 

The  results  presented  in  this  paper  are  part  of  the  Office  of  Naval 
Technology  (ONT)  ECS  effort.  This  program  was  developed  to  Integrate  systems 
engineering  capabilities  for  developing  large-scale,  real-time,  complex, 
computer  intensive  systems.  The  goal  of  the  ECS  effort  is  to  improve  the  way 
in  which  the  Navy  currently  creates,  maintains  and  improves  its  systems  by 
incorporating  state-of-the-art  technology  and  supplying  new  technology  where 
holes  in  present  methods  exist.  The  ECS  block  is  divided  into  four  projects; 
Systems  Design  Synthesis  Technology,  Systems  Evaluation  and  Assessment 
Technology,  Systems  Reengineering  Technology,  and  Engineering  Application 
Prototype.  These  projects  work  closely  together  to  incorporate  new  technology 
across  the  entire  system  development  life  cycle. 

The  Requirements  Specification  and  Traceability  Task  is  within  the 
Systems  Design  Synthesis  Technology  Project.  The  project  looks  at  the  forward 
engineering  aspects  of  the  system  life  cycle.  The  task  will  work  closely  with 
the  Systems  Design  Capture  and  Analysis  Task  (within  the  same  project)  to 
ensure  that  the  requirements  provide  all  the  information  for  the  systems 
engineers  to  fully  capture  the  design. 

Typically,  the  requirements  for  real-time,  complex  Navy  systems  are 
developed  by  technical  and  operational  Navy  experts.  These  experts  need  to 
specify  the  requirements  in  a  manner  in  which  they  are  comfortable.  Usually, 
this  means  a  combination  of  English  text  and  diagrams.  Formal  specification 
methods  which  are  hi^ly  mathematical  are  less  intuitive  than  English  text; 
therefore,  it  may  be  more  difficult  for  the  experts  to  validate  that  the 
formal  requirements  represent  their  intentions. 

The  requirements  for  large-scale,  real-time,  complex,  computer-intensive 
systems  may  be  defined  In  thousands  of  pages  of  documents,  usually  specified 
in  a  rather  informal  manner  by  several  different  experts.  These  requirements 
must  completely,  consistently,  unambiguously  and  correctly  achieve  the  goals 
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that  the  requirements  developers  have  In  mind.  A  representation  needs  to  be 
created  to  specify  these  requirements  In  a  manner  that  can  be  easily  checked 
to  ensure  the  presence  of  these  characteristics,  even  as  it  goes  through 
modifications  and  changes. 

Currently,  there  are  formal  specification  languages  that  allow  for  some 
checking  of  requirements.  These  languages  tend  to  specify  only  certain  pieces 
of  a  complex,  mission  critical  system  (i.e.,  hardware  requirements,  software 
requirements,  etc.).  These  languages  also  tend  to  be  limited  to  specifying 
only  some  aspects  of  a  complex  system  (i.e.,  data  requirements,  behavior 
requirements,  functional  requirements,  etc.).  Existing  requirements 
specification  checking  techniques  are  usually  restricted  to  simple  consistency 
checks  and  do  not  fully  support  completeness  and  correctness  checking. 

In  addition  to  checking  the  requirements,  a  method  needs  to  be  developed 
to  ensure  that  the  design  meets  these  specified  requirements.  As  part  of  the 
system  development  and  maintenance  process,  many  decisions  and  trade-offs  must 
be  made  in  the  design  of  the  system.  In  large  systems,  even  the  requirements 
themselves  go  through  many  changes  during  the  development  phase.  It  is 
necessary  that  with  all  these  changes,  the  design  still  meets  the  specified 
(latest)  requirements.  To  guarantee  this,  requirements  traceability 
throughout  the  systems  engineering  process  is  imperative;  if  the  development 
process  cannot  be  traced  back  to  the  requirements,  errors  will  occur. 
Similarly,  all  system  components  throughout  each  level  of  the  development 
process  must  be  able  to  be  linked  back  to  the  requirements.  These  links  must 
be  bidirectional  to  allow  requirements  tracing  forward,  from  requirements  to 
system  components,  and  backward,  from  system  components  to  requirements. 
Traceability  must  be  maintained  through  all  levels  of  the  systems  engineering 
process,  from  the  problem  as  stated  (or  contracted)  by  the  customer,  throu^ 
analysis,  design,  coding  and  testing  to  the  final  product.  The  theoretical 
background  that  allows  the  representation  and  linking  of  system  requirements, 
at  the  highest  level,  through  progressive  phases  of  system  hardware,  software 
and  humanware  development  needs  to  be  formally  developed.  These  techniques 
will  provide  the  basis  for  an  automated  system  for  requirements  traceability. 


1.2  ROADMAP 

The  remainder  of  this  paper  describes  the  RESPECT  methodology  along  with 
Justifications.  Chapter  2  describes  the  motivation  for  the  approach  that  the 
research  effort  is  taking.  Chapter  3  describes  the  details  of  the  RESPECT 
methodology.  Chapter  4  looks  at  the  feasibility  of  the  approach  based  on 
existing  technology.  Finally,  Chapter  5  looks  at  future  plans  for  this 
research  effort. 
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CHAPTER  2 
MOTIVATION 


The  RESPECT  methodology  has  evolved  from  a  preliminary  examination  of 
how  the  Navy  currently  specifies  and  traces  requirements  and  the  current 
state-of-the-art  technology.  The  motivation  for  this  effort  Is  broken  Into 
three  sections:  specifying  correct  and  consistent  system  requirements, 
tracing  the  requirements  through  the  design,  and  examining  the  shortfalls  In 
the  state-of-the-art  technology. 


2.1  SPECIFYING  CORRECT  AND  CONSISTENT  SYSTEM  REQUIREMENTS 

Building  correct  and  long  lasting  large-scale,  real-time,  complex, 
computer- Intensive  systems  starts  with  specifying  correct  and  consistent 
system  requirements.  If  the  requirements  do  not  correctly  reflect  the 
Intentions  of  the  domain  experts,  then  the  system  will  not  be  built  according 
to  their  needs.  Important  decisions  which  eliminate  Inconsistencies  and 
clarify  ambiguities  In  the  requirements  are  often  made  by  the  system  designers 
when  they  should  be  made  by  the  domain  experts.  For  most  Navy  systems  the 
requirements  are  developed  by  the  Navy  and  passed  on  to  contractors  for 
analysis  and  system  design.  All  the  Information  concerning  what  the  system 
sh^'tild  do  needs  to  be  Fpeclfled  at  this  time.  In  order  to  ensure  that  the 
system  will  function  as  required  by  the  Navy,  these  requirements  must  be 
specified  completely,  unambiguously  and  correctly,  so  that  the  contractors  can 
develop  the  system  without  having  to  Interpret  the  requirements. 

Currently,  the  Navy  specifies  their  requirements  to  contractors  In 
documents.  These  documents  are  usually  thousands  of  pages  In  length  and  are 
developed  by  several  different  domain  experts.  They  contain  all  the 
Information  regarding  what  the  system  should  do  and  any  Implementation 
constraints  that  fit  the  Navy's  specific  needs.  The  functionality  of  the 
system  Is  fully  described.  All  critical  behavior  and  timing  of  the  system  Is 
specified.  Physical  properties  such  as  size  and  wei^t  of  the  system  are  also 
Included.  The  Navy  also  specifies  certain  constraints  that  limit  the  freedom 
that  the  contractor  has  on  designing  the  system.  These  constraints  Include 
the  use  of  specific  hardware,  software  languages,  operating  systems  and 
windowing  environments.  Sometimes  it  Is  necessary  to  constrain  the  analysis 
or  design  of  parts  of  the  system.  For  example,  some  systems  might  require  the 
use  of  a  specific  functional  breakdown  for  a  part  of  the  system. 

The  present  method  of  specifying  Navy  requirements  Is  very  Informal.  It 
consists  mostly  of  English  narrative  with  some  diagrams  and  supporting  charts. 
There  Is  no  systematic  method  of  checking  for  consistency  of  Information,  or 
for  Identifying  ambiguities,  leaving  their  resolution  to  the  contractors. 
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These  Inconsistencies  and  ambiguities  are  inevitable  since  the  requirements 
are  developed  by  more  then  one  expert  using  an  imprecise  language  (English) . 

A  formal  method  would  allow  the  requirements  developers  to  resolve  these 
issues  by  checking  the  requirements  for  consistency  and  ambiguities  before  the 
contractors  performed  any  detailed  requirements  analysis  or  design. 


2.2  MAINTAINING  CONSISTENCY  BETWEEN  REQUIREMENTS  AMD  DESIGN 

Maintaining  consistency  between  the  requirements  and  the  design  is  one 
of  the  key  issues  in  developing  a  correct  and  long  lasting  system.  This 
includes  both  determining  if  the  design  and  implementation  initially  meets  the 
requirements,  and  maintaining  requirements,  design,  and  implementation 
consistency  throughout  the  system  development  life  cycle.  Since  the  Navy 
typically  relies  on  contractors  to  design  and  build  large,  complex  real-time 
computer  Intensive  systems,  having  a  systematic  way  of  validating  that  every 
requirement  is  met  by  the  design  is  important,  not  only  to  ensure  that  the 
system  performs  correctly,  but  also  to  determine  whether  contractual 
obligations  have  been  met. 

Post  deployment  support  is  essential  to  the  development  life  cycle  of 
Navy  systems.  Systems  introduced  into  the  Navy's  fleet  tend  to  remain  for 
long  periods  of  time  due  to  the  amount  of  cost  and  time  it  takes  to  develop 
new  systems.  This  is  especially  true  during  the  current  environment  of 
declining  defense  dollars.  Fixing  problems  and  developing  enhancements  to 
existing  systems  are  critical  in  support  of  the  fleet. 

Any  change  to  a  complex  system  can  have  effects  which  may  not  be  obvious 
to  the  malntalner  of  the  system.  An  example  of  this  happened  July  1991  when 
the  C  &  P  telephone  company  had  a  large  part  of  their  switching  network  shut 
down  by  a  bug  in  their  computer  software.  According  to  the  Washington  Post, 
the  bug  was  caused  by  a  "minor"  software  change  made  by  DSC  Communications 
Corporation.  A  Vice  President  of  DSC  stated  that  "The  software  was  sent  out 
without  major  testing  because  DSC  Judged  that  the  changes  were  too  small  to 
require  it."^  These  "small"  changes  shut  down  telephone  services  in  three 
states  for  over  a  six-hour  period.  Although  the  shutting  down  of  the  phone 
company  had  a  major  effect  across  the  country,  it  does  not  compare  with  the 
disastrous  consequence  that  unforeseen  effects  of  a  "small"  change  can  have  in 
a  sonar  or  weapons  system  especially  during  wartime. 

These  types  of  "bugs"  might  be  avoided  with  proper  traceability  and 
system  maintenance  techniques.  These  techniques  show  a  relationship  between 
each  element  of  the  design  and  the  requirements.  Any  change  to  the  design  can 
be  analyzed  to  determine  if  the  system  still  meets  every  requirement.  Since 
every  requirement  that  is  affected  by  a  part  of  the  design  is  linked  through 
the  traceability  techniques,  any  effects  on  requirements  that  the  system 
malntalner  may  not  have  considered  will  be  examined.  This  cuts  down  on  the 
possibility  of  requirements  that  were  Initially  met  by  a  part  of  the  design 
not  being  met  due  to  a  change  in  a  piece  of  the  design. 
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2.3  SHORTFALLS  IN  CURRENT  TECHNIQUES 

In  order  to  ImpleaaDt  a  methodology  such  as  RESPECT,  the  technology  must 
be  mature  enough  to  support  It.  The  current  state-of-the-art  for  both 
requirements  specification  and  traceability  techniques  are  not  robust  enough 
to  fully  meet  all  the  Navy  needs.  This  section  describes  some  of  the 
shortfalls  in  today's  technology,  which  is  one  of  the  reasons  for  continuing 
to  research  this  area. 


2.3.1  Shortfalls  in  Current  Requirements  Specification  Techniques 

Some  of  the  current  problems  with  requirements  specification  languages 
were  listed  in  the  Requirements  Engineering  and  Rapid  Prototyping  Workshop 
Proceedings .  which  was  sponsored  by  the  US  Army  CECOM  Center  for  Software 
Engineering.  According  to  the  findings  of  this  workshop,  current  requirements 
specification  languages  lack  the  following: 

*  They  do  not  capture  requirements  information  effectively  to  support  the 
system  evolution; 

*  They  do  not  specify  nonfunctional  requirements; 

*  There  is  no  automated  way  to  reflect  changes  to  the  systems  in  the 
requirements  or  vice  versa; 

*  They  do  not  represent  diverse  viewpoints; 

*  There  are  too  many  gaps  in  the  formalisms  that  represent  system 
requirements ; 

*  There  are  too  many  facts  that  have  to  be  known  before  any  requirements 
specification  languages  can  be  used.^ 


Current  requirements  specification  and  traceability  tools  (i.e., 
Teamwork/RQT ,  R-trace,  etc.)  allow  for  a  manual  parsing  and  grouping  of 
functional  requirements.  There  is  no  systematic  method,  either  syntactic  or 
semantic,  in  which  requirements  can  be  grouped.  There  is  also  no  automated 
checking  of  the  requirements  for  consistency  or  ambiguity.  Requirements  which 
are  grouped  together  can  be  manually  labeled  as  ambiguous  or  inconsistent,  but 
these  designations  are  based  strictly  on  the  individual’s  analysis  of  the 
requirements  and  are  not  systematic  or  repeatable. 


2.3.2  Shortfalls  in  Current  Requirements  Traceability  Techniques 

The  current  commercial  state-of-the-art  requirements  traceability 
techniques  (i.e.,  Teamwork/RQT,  R-trace,  RDD-100)  simply  link  requirements  to 
pieces  of  the  design  and  implementation.  They  relate  parts  of  requirements 
documents  to  a  database  tdiich  represents  the  pieces  of  system  design  and 
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Inplementatlon.  These  techniques  do  not  capture  how  the  requirement  Is 
satisfied  by  the  design,  Just  the  fact  that  some  relationship  exists. 

Another  shortfall  with  today's  traceability  tools  Is  that  they  lack  the 
ability  to  trace  back  from  the  actual  pieces  of  design  and  Implementation  to 
the  requirements.  Although  some  tools  such  as  Teamwork/RQT  and  R-trace  allow 
the  user  to  trace  from  requirements  analysis  tools  such  as  Teamwork  and 
Software  Through  Pictures,  they  do  not  have  a  method  for  tracing  from  a 
particular  piece  of  hardware  or  humanware  back  to  the  requirements.  This 
capability  would  be  extremely  useful  In  performing  systems  maintenance. 
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CHAPTER  3 
APPROACH 


The  RESPECT  methodology  approach  Is  divided  Into  three  parts.  The  first 
part  looks  at  natural  interfaces  for  requirements  specification.  The  second 
part  develops  a  formal  requirements  representation.  The  last  part  looks  at 
techniques  for  maintaining  consistency  between  requirements  and  design.  This 
chapter  gives  an  overview  of  the  RESPECT  methodology  and  then  gives  a  detailed 
explanation  of  all  three  parts. 


3.1  OVERVIEW  OF  METHODOLOGY 

The  RESPECT  methodology  examines  the  requirements  specification  and 
traceability  challenge  in  its  entirety.  It  examines  the  problem  in  the 
abstract  and  does  not  limit  itself  to  today's  technology.  The  approach  looks 
towards  the  long-term  and  incorporates  ideas  which  makes  use  of  tomorrow's 
technology  as  well  as  today's. 

It  is  often  said  that  one  person's  design  is  another  person's 
requirement  and  vice  versa.  It  is  therefore  necessary  to  define  these  terms 
in  the  context  of  the  RESPECT  method  before  further  explaining  the  approach. 
The  term  "requirements"  refers  to  the  top-level  system  requirements  that  are 
specified  by  the  operational  personnel  at  the  initial  stage  of  a  system's 
development.  The  term  "design"  is  used  to  represent  every  stage  in  the  system 
development  life  cycle  after  the  specification  of  requirements.  This  includes 
what  is  traditionally  known  as  requirements  analysis,  design,  detailed  design, 
testing  and  maintenance.  The  term  "domain  expert"  refers  to  a  person  who 
originates  requirements  and  is  an  expert  in  a  particular  application  area;  it 
is  used  interchangeably  with  the  term  "requirements  originator." 

The  methodology  divides  the  requirements  aspect  of  system  development 
into  three  parts.  The  first  part  is  the  conceptual  view  which  represents  the 
Intentions  of  the  domain  experts  who  did  the  initial  development.  The  second 
part  is  the  formal  representation  which  ensures  that  the  requirements  are 
captured  both  completely  and  consistently.  The  final  part  is  the  design 
elements  to  which  the  requirements  are  traced.  The  method  uses  the  term 
"design  element"  to  denote  any  part  of  the  system  design  or  Implementation 
(i.e.,  data  flow  diagrams,  code,  pieces  of  hardware,  humanware,  structure 
charts  etc.). 

It  is  Important  that  the  requirements  and  design  remain  consistent 
throughout  the  entire  system  development  process.  The  conceptual  view  of  the 
requirements  must  be  completely  and  correctly  presented  to  the  designers 
through  the  formal  representation  and  interfaces.  The  designers  mvist  then  be 
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able  to  demonstrate  that  the  final  cesign  meets  the  Intentions  of  the 
requirements  originators  through  traceability  and  interfaces.  This 
methodology  allows  for  a  formal  representation  of  the  conceptual  view  of  the 
requirements  in  a  manner  which  ensures  the  integrity  of  the  requirements  and 
presents  the  requirements  clearly  to  both  the  requirements  originators  and  the 
designers. 

Figure  3-1  gives  a  pictorial  view  of  the  approach  taken  by  this  research 
effort  showing  all  three  parts  and  how  they  are  related.  The  cloud  figure 
represents  the  conceptual  requirements  which  the  requirements  originators  have 
in  their  minds.  These  ideas  are  captured  through  interfaces,  which  might  be 
natural  language  or  graphical,  into  a  formal  representation.  The  requirements 
are  then  checked  for  consistency,  ambiguity  and  completeness  through  the 
formal  representation.  The  requirements  originators,  through  the  use  of  the 
interfaces,  check  the  formal  structure  for  correctness.  Finally  the 
requirements  are  traced  from  the  formal  representation  to  the  system  design 
elements . 
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The  methodology  will  specify  the  requirements  for  building  interfaces 
which  ensure  that  the  formal  requirements  meet  the  original  intentions  of  the 
domain  experts.  This  will  be  done  by  presenting  the  requirements  to  the 
domain  experts  in  a  way  which  is  complete,  unambiguous  and  natural  to  them. 

In  this  way,  the  requirements  originators  can  check  the  correctness  of  the 
requirements  after  they  have  been  formally  captured  without  having  to 
understand  the  mathematical  formalisms  which  comprise  the  formal 
representation . 

Within  RESPECT,  the  methodology  will  create  a  syntax  for  a  formal 
requirements  representation.  This  representation  will  allow  for  an  assurance 
of  the  requirements  integrity  without  being  biased  toward  a  particular  view  or 
perspective  of  the  system.  The  representation  will  be  mathematical  and 
logical  in  nature  and  will  require  different  Interfaces  to  allow  the 
requirements  originators  and  the  designers  to  view  them  properly. 

Also,  systematic  techniques  for  ensuring  consistency  between  the 
requirements  representation  and  the  design  will  be  created.  This  will  be  done 
through  interfaces,  traceability  techniques,  and  by  automating  the  process  of 
transforming  the  requirements  representation  to  present  design  methods.  These 
techniques  will  confirm  that  the  final  design  and  implementation  meet  the 
requirements  as  presented  in  the  requirements  representation. 


3.2  NATURAL  EXTRACTION  OF  REQUIREMENTS  INFORMATION 

One  major  step  in  the  requirements  process  is  presenting  the  formal 
requirements  to  the  domain  experts  using  natural  techniques,  i.e.,  English  and 
graphical.  This  is  Important  to  prevent  errors  during  the  initial 
specification  of  the  requirements  as  well  as  for  the  process  of  reviewing  the 
requirements  for  correctness. 

Typically,  several  different  experts  with  widely  varying  backgrounds  are 
Involved  in  developing  requirements  for  large  complex  systems.  These  experts 
are  only  responsible  for  specifying  certain  areas  of  the  system  and 
consequently  are  only  interested  in  viewing  Information  which  relates 
directly,  or  Indirectly,  to  those  areas  of  the  system.  It  is  therefore 
important  that  each  domain  expert  be  able  to  view  the  full  set  of  requirements 
through  their  specific  perspective. 


3.2.1  Different  Domain  Perspectives 

Figure  3-2  shows  how  the  different  system  domains  fit  into  the  RESPECT 
methodology.  The  requirements  are  broken  up  to  represent  the  different  domain 
experts  who  develop  requirements.  Each  expert  has  his  own  perspective  of  the 
system.  The  perspectives  are  Integrated  by  the  interface  to  form  the  formal 
representation.  The  interfaces  also  display  the  requirements  according  to 
each  expert's  perspective. 
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FIGURE  3-2.  PERSPECTIVES 


Each  domain  perspective  contains  Infonnatlon  that  overlaps  the  different 
domains.  A  domain  expert  will  probably  need  to  view  all  the  requirements 
Information  relating  to  his  particular  domain,  but  only  some  of  the 
Information  In  the  other  domains.  It  Is  Important  that  the  domain  experts  can 
limit  the  information  viewed.  For  example,  an  expert  creating  the 
requirements  for  a  hydrophone  or  receiver  of  an  active  sonar  system  needs  to 
know  all  the  Information  of  the  hydrophone  Including  Its  frequency,  wel^t  and 
environmental  constraints.  The  hydrophone  expert  also  probably  needs  to  know 
the  frequency  of  the  projector  or  transmitter,  but  ml^t  not  need  to  know  the 
wei^t  constraints  or  environmental  conditions  of  the  projector.  He  needs  to 
be  able  to  view  the  projector's  requirements  which  are  pertinent  to  the 
hydrophone  without  being  distracted  by  all  the  other  requirements  of  the 
projector.  This  Is  extremely  Important  In  large  systems,  because  the  niimber 
of  requirements  are  numerous  and  their  relationships  are  complex. 
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3.2.2  Natural  Interfaces 

In  order  to  allow  the  domain  experts  to  specify  and  review  the  formally 
represented  requirements,  natural  Interfaces  need  to  be  built.  There  are  two 
natural  methods  of  specification:  graphical  interfaces  and  English 
Interfaces.  A  combination  of  the  two  approaches  is  likely  to  be  the  most 
effective 

3. 2. 2.1  Graphical  Interfaces.  Graphical  interfaces  represent  the 

requirements  in  a  form  other  than  text.  This  is  useful  for  presenting  the 
requirements  in  a  manner  which  is  natural  to  the  eye.  They  are  also  tiseful 

for  displaying  states,  control,  relationships  and  hierarchies. 

One  way  to  adapt  to  graphical  interfaces  is  through  the  use  of  an  expert 
system  shell  to  create  an  interactive  environment.  The  expert  system  shell 
acts  as  a  guide,  asking  the  requirements  generators  leading  questions  to  help 
set  up  their  environment.  This  is  extremely  useful  when  an  ambiguous  textual 
description  of  the  requirements  already  exists  and  the  transition  needs  to  be 
made  to  a  more  graphical  form. 

3. 2. 2. 2  English  Interfaces.  The  English  language  is  extremely 
imprecise.  This  makes  creating  an  automatable  process  for  converting  English 
text  into  a  formal  structure  very  difficult.  Parsing  text  is  the  first  step 
in  converting  from  English  text  to  a  more  formal  language.  Parsing 

is  the  partitioning  of  the  requirements  document  into  parts  in  order  to  better 
understand  the  requirements.  Parsing  can  be  done  manually  or  systematically 
according  to  syntax  or  semantics. 

3. 2. 2. 2.1  MANUAL  PARSING.  Manual  parsing  requires  the  knowledge  of 
domain  experts  or  system  designers  to  partition  the  requirements.  These 
experts  look  through  the  requirements  and  extract  the  necessary  Information  to 
create  the  formal  requirements.  Manual  parsing  is  neither  systematic  nor 
repeatable;  but  given  the  imprecise  nature  of  the  English  language,  some 
manual  parsing  will  probably  be  necessary  when  converting  from  English  to  the 
formal  representation. 

3. 2. 2. 2. 2  SYSTEMATIC  PARSING  (AUTOMATABLE).  A  systematic  method  of 
parsing  a  requirements  document  is  preferable  to  a  manual  one.  A  systematic 
method  divides  the  requirements  according  to  rules.  These  irules  can  either  be 
generic  to  all  requirements  or  domain  specific  to  the  system  under  design.  A 
systematic  method  for  parsing  requirements  is  both  repeatable  and  automatable. 
There  are  two  types  of  systematic  parsing;  syntactic  and  semantic. 

Syntactic  parsing  is  breaking  the  requirements  down  according  to 
specific  words  and  structures.  This  is  a  first  step  in  organizing  the 
requirements  in  a  formal  manner.  For  example,  a  syntactic  parser  can  extract 
all  the  statements  in  a  docvunent  following  the  word  "shall."  This  would  allow 
for  easy  identification  of  statements  of  what  the  system  must  do.  A  parser 
could  also  break  the  paragraphs  into  individual  sentences.  Then  each  sentence 
could  be  Identified  as  a  different  requirement.  Syntactic  parsing  can  also 
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include  grouping  all  the  sentences  which  contain  a  specific  keyword  (i.e., 
threat,  hydrophone,  projector,  etc.)* 

Semantic  parsing  is  breaking  the  requirements  down  according  to  specific 
meaning.  This  process  is  difficult  to  do  with  the  Informality  of  the  English 
language.  Semantic  parsing  techniques  may  be  developed  for  specific  domains 
because  the  same  words  and  phrases  are  often  used.  Some  examples  of  semantic 
parsing  are  grouping  phrases  or  sentences  which  contain  related  keywords 
(i.e.,  targets,  submarines  and  ships)  and  grouping  paragraphs  or  sections  that 
are  related  either  within  or  across  documents. 


3.3  FORMAL  REPRESENTATION 

The  formal  requirements  representation  will  be  used  to  fully  capture  the 
requirements.  It  will  act  as  a  buffer  between  the  people  who  generate  the 
requirements  and  the  designers  of  the  systems.  The  representation  will  allow 
for  the  requirements  to  be  verified  before  any  partitioning  of  the 
requirements  or  designing  of  the  system  takes  place.  The  representation  will 
consist  of  formal  specification  languages  which  will  be  used  to  capture  and 
analyze  the  requirements.  These  languages  check  the  requirements  for 
consistency  and  can  prove  certain  assertions  about  the  system.  The 
representation  will  also  be  open  and  flexible  enough  to  allow  for  interfaces 
and  traceability  techniques  to  be  built  around  the  representation. 


3.3.1  Using  Several  Specification  Languases 

The  Systems  Design  Capture  and  Analysis  Task  determined  that  to  fully 
capture  the  design  of  a  system,  several  views  of  the  system  need  to  be 
examined.^**  The  requirements  for  a  system  must  contain  all  the  information 
necessary  to  capture  all  the  views  during  system  design.  Also,  the  types  of 
requirements  information  is  diverse.  The  requirements  contain  hardware, 
humanware  and  software  constraints,  functional  requirements,  nonfunctional 
requirements,  behavior,  and  real-time  attributes  as  well  as  testing  and 
documentation  procedures.  The  formal  representation  must  fully  capture  all  the 
requirements  of  the  system.  This  may  require  the  use  of  more  than  one 
specification  language  in  the  requirements  representation.  Present  day 
specification  techniques  seem  to  capture  part  of  a  system  very  well.  Some 
languages,  such  as  Modechart,’  capture  behavior  while  other  techniques,  such 
as  entity  relationship  diagrams,  capture  the  required  objects  of  the  system 
and  how  they  relate.  Combining  a  number  of  these  languages  and  developing  a 
method  to  check  consistency  across  these  languages  will  allow  full  capture  of 
all  the  requirements  of  a  system. 

3.3.2  Criteria,  of  Requirements  Specification  Techniques 

In  order  to  determine  the  best  notation  for  fully  capturing  the  formal 
requirements,  an  evaluation  of  state-of-the-art  requirements  specification 
languages  is  being  performed.  As  a  first  step  to  evaluating  the  requirements 
specification  languages,  a  number  of  criteria,  against  which  the  specification 
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languages  will  be  judged,  has  been  created.  These  criteria  include  properties 
for  formally  capturing  a  complete  system  (i.e.,  scope),  formal  methods  for 
checking  a  system  (i.e.,  consistency,  completeness,  etc.),  properties  specific 
to  specifying  large-scale,  complex  systems  (i.e.,  real-time,  scalability, 
etc.),  and  properties  concerning  the  implementation  of  the  method  (i.e.,  how 
well  the  language  can  Interface  with  other  specification  languages,  ease  of 
tise  of  interface ,  etc . ) .  A  detailed  description  is  presented  in  Technical 
Memorandum  5530—100:  Evaluation  Criteria  for  Real-Time  Specifications 
Languages .  published  by  the  Naval  Research.  Laboratory  (NRL)  and  included  as 
Appendix  A  to  this  document. 


3.4  CONSISTENCY  BETWEEN  FORMAL  REQUIREMENTS  AND  THE  DESIGN 

Creating  and  maintaining  a  correct  and  consistent  set  of  requirements 
does  not  guarantee  a  properly  operational  final  system.  The  designed  system 
must  also  meet  the  specified  requirements.  Maintaining  consistency  between 
requirements  and  design  can  be  done  in  two  ways:  through  traceability 
techniques  and  by  direct  transformation  from  the  requirements  representation 
to  design. 


3.4.1  Traceability 

Traceability  provides  a  relationship  between  the  requirements,  the 
design,  and  the  final  implementation  of  the  system.  Showing  these 
relationships  aids  both  the  designers  and  testers  in  many  areas.  It  allows 
the  designers  to  demonstrate  that  their  design  meets  the  requirements  and  also 
allows  for  easy  recognition  of  those  requirements  which  have  not  yet  been  met 
by  the  design.  Some  of  the  Implications  of  a  requirements  change  during  or 
after  the  development  of  the  design  can  be  determined  before  system  redesign 
takes  place.  One  of  the  greatest  advantages  of  traceability  is  evident  in  the 
post  deployment  phase  of  the  system  life  cycle.  By  effectively  relating  each 
requirement  to  a  specific  design  element,  the  testers  and  designers  can 
determine  the  effects  of  changing  the  design  on  the  requirements. 

Traceability  can  be  implemented  at  two  levels:  on-line  and  through 
reports.  On-line  traceability  allows  a  direct  interactive  means  of 
referencing  a  design  element  back  to  the  original  requirement (s)  (i.e., 
clicking  on  a  bubble  of  a  data  flow  diagram  and  being  able  to  see  the 
requirement (s)  that  the  bubble  satisfied,  or  tracing  a  particular  sub-routine 
of  code  back  to  its  initial  requirement(s)  or  functional  representation) . 

This  type  of  traceability  is  advantageous  idten  trying  to  determine  the  effects 
due  to  a  change  in  the  design  or  a  change  in  the  requirement  after  the  system 
is  already  developed. 

Traceability  through  reports  allows  the  designer  to  see  which 
requirements  are  satisfied  through  a  matrix  of  tables.  These  reports  can  give 
information  based  on  a  variety  of  keys;  such  as  requirements,  design  elements, 
unsatisfied  requirements,  etc.  This  type  of  traceability  is  especially  useful 
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in  determining  the  completeness  of  the  design.  Both  on-line  and  report 
traceability  are  necessary  to  completely  maintain  a  system. 

3. 4. 1.1  Traceability  Domains.  In  order  for  a  traceability  technique  to 
be  effective  it  must  allow  the  designer  to  trace  the  requirements  through  each 
stage  of  the  design.  It  is  Important  that  traceability  is  consistent  at  every 
level  of  the  design  and  that  there  is  direct  traceability  between  the  design 
levels  as  well  as  between  the  requirements  and  the  design.  Tnis  ensures  that 
changes  made  in  later  design  stages  get  reflected  back  to  earlier  stages  in 
the  system's  development  (l.e.,  changes  made  during  detail  design  need  to  be 
reflected  in  the  design  and  requirements  analysis  phases) .  Figure  3-3 
demonstrates  some  of  the  different  design  stages  and  how  the  relationships 
between  requirements,  design  and  implementation  need  to  be  documented. 


FIGURE  3-3.  TRACEABILITY  DOHAINS 


The  stages  in  system  development  range  from  the  original  English 
requirements  through  the  internal  representation,  requirements  analysis  and 
top  level  design,  down  to  detailed  design  and  implementation.  Each  stage  has 
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its  own  set  of  different  notations  and  methodology.  These  notations  require 
different  methods  of  relating  their  parts  of  the  system  back  to  the 
requirements  and  to  the  other  stages  of  design.  It  Is  Imperative  that  every 
design  stage  is  linked  to  every  other  design  stage  so  that  the  effects  of  a 
change  to  a  particular  stage  Is  reflected  throughout  the  entire  design. 

One  of  the  most  difficult  Issues  involved  In  traceability  concerns 
linking  requirements  to  the  Implementation  of  the  system.  Since  the 
implementation  of  systems  Involves  hardware,  software  and  humanware,  more 
robust  tracing  methods  may  apply.  Typically,  tracing  techniques  lend 
themselves  to  design  objects  which  are  stored  In  a  computer  c^tabase  (l.e., 
data  flow  diagrams,  pieces  of  code,  requirements  documents,  etc.)  since  It  Is 
relatively  easy  to  attach  comments  and  notes  to  any  design  element  which  Is 
stored  In  a  computer.  Tracing  pieces  of  hardware  and  humanware  back  to  the 
requirements  Is  more  difficult  because  there  Is  no  technique  for  attaching  the 
Information  directly  to  the  design  element.  A  computer  representation  of  the 
design  elements  can  be  developed  (l.e.,  Teamwork/RQT)  but  that  does  not  allow 
direct  traceability  from  the  design  element  back  to  the  requirement. 

Within  each  stage  In  the  system  development  life  cycle,  the  system  may 
be  viewed  In  different  ways.  Traceability  must  be  maintained  within  these 
separate  views  which  are  defined  by  the  Design  Capture  and  Analysis  Task  of 
the  ECS  block. ^  These  views  are  Functional,  Informational,  Environmental, 
Behavioral  and  Implementation.  Each  view  contains  different  Information  but 
some  Information  overlaps  from  one  view  to  another.  Traceability  Is  Important 
between  these  views  so  that  consistency  Is  maintained.  Each  view  of  the 
system  Is  captured  using  different  methods  so  different  linking  techniques  may 
need  to  be  developed  to  trace  to  each  view. 

3. 4. 1.2  Linking  Technology.  Linking  is  one  method  of  relating  the 
requirements  to  the  design  elements.  For  large  systems  these  links  need  to  be 
automated  through  a  computer  database  or  Hypertext  system. 

Present  methods  allow  some  traceability  by  using  simple  linking 
techniques  to  relate  requirements  to  design.  These  methods  do  not  annotate 
the  types  of  relationships  that  exist  between  the  requirements  and  design. 
Complex  linking  techniques,  which  would  show  the  specific  relationships 
between  the  requirements  and  the  design,  will  allow  the  designer  to  better 
understand  the  system  and  the  effects  that  changes  to  the  design  will  have 
with  respect  to  the  requirements. 

Figure  3-4  shows  the  manner  In  which  most  traceability  tools  link 
requirements  to  design.  The  links  are  simple  In  that  they  do  not  reflect  any 
meaning  behind  the  relationships  between  requirements  and  design.  In  this 
case,  the  links  show  that  requirement  A  Is  somehow  satisfied  by  design 
elements  one,  two  and  three.  Figure  3-5  shows  one  complex  method  of  linking 
which  uses  combinatorial  logic  to  display  how  the  design  elements  satisfy  the 
requirements.  An  example  of  this  Is  shown  In  Figure  3-6.  In  this  example,  the 
requirement  "target  sub"  Is  being  satisfied  by  the  design  elements  "passive 
sonar,"  "active  sonar"  and  "display."  The  combinatorial  logic  method  shows  a 
specific  relationship  between  "target  sub"  and  the  three  design  elements. 
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"Target  sub"  is  being  satisfied  in  the  system  by  the  "display"  AND  "active 
sonar"  OR  "display"  AND  "passive  sonar."  This  representation  describes  the 
relationship  between  the  three  components  and  the  requirement. 


FIGURE  3-5.  COMPLEX  LINKING 
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FIGURE  3-6.  COMPLEX  LINKING  (EXAMPLE) 


Another  method  of  complex  linking  captures  the  conditions  under  which  a 
design  element  satisfies  a  requirement.  Using  the  above  example,  the  "target 
sub"  requirement  can  be  satisfied  by  "active  sonar"  under  the  condition  that 
the  system  is  already  detected  by  the  targeted  sub.  If  the  system  is  not 
already  detected,  then  the  requirement  Is  satisfied  by  the  design  elements 
■passive  sonar"  and  "display." 

Another  method  of  specifying  a  relationship  between  requirements  and 
design  elements  Is  by  capturing  design  decisions.  By  documenting  the 
assvunptlons ,  options  and  reasons  why  a  system  designer  makes  certain 
decisions,  the  manner  In  which  a  design  element  meets  a  requirement (s)  Is  also 
captured.  It  Is  also  Important  that  these  design  decisions  are  captured 
formally  so  that  a  change  In  an  assumption  can  produce  an  automated  change  In 
design.* 


3.4.2  Automated  Transition  from  Representation  to  Design 

One  method  of  ensuring  consistency  between  requirements  and  design  is  by 
using  automated  techniques  to  transfer  the  information  from  the  requirements 
representation  to  the  parts  of  the  design.  If  similar  methods  are  used  to 
capture  the  requirements  Information  and  the  design  Information,  then 
automated  transitioning  from  one  representation  to  another  Is  possible.  This 
transitioning  would  guarantee  consistency  because  there  is  no  change  in  the 
Information.  The  problem  with  this  method  is  that  it  needs  to  be  back 
annotated.  If  a  change  is  made  to  the  design,  a  method  must  also  exist  to 
reflect  those  changes  back  to  the  requirements. 
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3.4.3  Marking  Satisfied  Requirements 

One  important  consequence  of  traceability  is  the  ability  to  determine  if 
the  requirements  are  satisfied  by  the  design.  This  feature  is  especially 
essential  for  DOD  work  since  the  designing  and  constructing  of  the  system  is 
typically  performed  by  contractors.  The  major  issues  concerned  with  marking 
requirements  include  showing  that  the  requirements  are  completely  satisfied  by 
the  design,  denoting  when  a  requirement  is  partially  satisfied  by  the  design, 
denoting  under  what  conditions  requirements  are  satisfied  and  determining  if 
nonfunctional  requirements  have  been  met  by  the  design. 

3.4. 3.1  Completely  Satisfied  Requirements.  The  RESPECT  methodology 
will  create  a  technique  for  consistently  marking  when  a  requirement  is 
completely  satisfied  by  the  design.  This  marking  system  will  be  maintainable 
so  that  checking  is  done  whenever  design  changes  are  made  to  ensure  that  the 
requirements  are  still  met  by  the  design.  Initially,  any  requirement  which  is 
traced  to  a  design  element,  and  then  changed,  will  be  flagged,  and  the 
designer  will  be  forced  to  check  that  all  requirements  relating  to  that 
changed  design  element  are  still  met.  Eventually  a  systematic  technique  will 
be  developed,  based  on  the  formal  capture  of  complex  linking  techniques,  to 
selectively  flag  the  requirements  that  are  affected  by  the  design  change. 

3. 4. 3. 2  Partially  Satisfied  Requirements.  Requirements  of  large,  real¬ 
time,  complex,  computer-intensive  systems  tend  to  be  met  by  several  design 
elements.  At  a  particular  stage  in  a  system's  development,  a  requirement 
might  only  be  partially  met  by  the  design.  A  method  for  marking  these 
requirements  as  being  partially  satisfied  will  be  developed.  These  markings 
will  not  only  indicate  that  the  requirement  is  partially  satisfied,  but  give 
additional  information  as  to  how  it  is  satisfied  and  what  is  needed  to 
completely  satisfy  the  requirement. 

3.4. 3. 3  Conditions  of  Satisfied  Requirements.  In  order  to  fully 
understand  if  the  requirements  are  satisfied  by  the  design,  it  is  important  to 
capture  the  conditions  under  which  certain  requirements  are  satisfied.  Some 
designs  will  fulfill  certain  requirements,  based  on  the  fulfillment  of  other 
requirements,  design  decisions  or  external  events.  It  is  necessary  to  capture 
and  monitor  these  conditions  to  ensure  that  the  requirements  are  satisfied 
under  all  operating  conditions. 

3.4. 3.4  Nonfunctional  Requirements .  Certain  requirements  are  not 
linked  to  any  particular  combination  of  design  elements  but  are  affected  by 
the  system  as  a  whole.  These  requirements  tend  to  be  nonfunctional 
requirements.  Some  examples  of  these  are  dependability,  security,  and  timing. 
The  methodology  will  create  a  method  for  determining  if  these  requirements  are 
satisfied  by  the  system  and  a  manner  for  marking  these  requirements  as 
satisfied.  Since  these  requirements  are  affected  by  any  change  to  the  design 
or  implementation,  keeping  track  of  how  they  are  satisfied  is  isqportant  to 
ensuring  that  these  requirements  are  met. 
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CHAPTER  4 
FEASIBILITY 


Some  of  the  ideas  presented  in  the  RESPECT  methodology  are  feasible 
using  today's  technology.  Other  ideas  will  require  the  advancement  of  new 
technology  before  they  can  be  successfully  implemented.  The  methodology  is 
addressing  the  requirements  problem  as  a  whole  and  is  attempting  to  provide  a 
complete  solution.  In  building  the  methodology  and  associate  prototypes  the 
project  does  not  want  to  rule  out  the  possibilities  that  can  be  created  by 
advancing  technologies.  The  following  describes  the  feasibility  of  each 
section  of  the  RESPECT  methodology.  The  emphasis  is  on  describing  the  areas 
of  research  which  are  currently  being  explored,  and  the  research  efforts  which 
will  be  explored  in  the  future  as  technology  matures.  Also  some  major  Issues 
concerning  the  development  and  implementation  of  the  RESPECT  methodology  are 
discussed. 


4.1  FEASIBILITY  OF  NATURAL  INTERFACES 

The  ideas  presented  in  this  paper  referring  to  natural  interfaces  will 
require  an  advancement  in  the  state-of-the-art  technology  for  natural 
specification  development.  The  research  effort  will  work  with  the  Natural 
Specification  and  Generation  Task  (scheduled  to  start  in  FY93)  to  help  make 
advances  in  this  area. 

One  area  that  is  currently  being  researched  is  using  an  expert  system 
shell  to  aid  users  in  parsing  English  requirements  and  converting  them  to  a 
graphical  interface.  This  method  is  interactive  with  the  user.  The  expert 
shell  asks  questions  of  the  user  to  guide  the  user  in  forming  the  graphical 
representation.  This  method  is  being  prototyped  by  Trident  Systems,  Inc. 


4.2  FEASIBILITY  OF  FORMAL  REPRESENTATION 

The  research  area  of  formal  specification  is  fairly  well  developed. 
There  are  several  requirements  specification  languages  and  techniques 
available  (i.e.,  Modechart,  Van  Schouwen  (Modified  SCR),  ASTRAL,  Hierarchical 
Multi-State  (HMS)  Machines,  Statemate)  and  others  which  are  still  under 
developswnt.  The  main  problem  with  the  specification  languages  is  their 
limited  scope.  Most  cannot  handle  all  the  information  that  needs  to  be 
specified  by  a  system.  The  difficulty  in  combining  these  languages  is  that 
SKist  of  the  languages  are  propriety  and  therefore  their  structure  is  not  open. 
This  makes  the  iBq>lementation  of  this  representation  difficult  to  develop. 
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4.3  FEASIBILITY  OF  TRACEABILITY  TECHNIQUES 

The  traceability  Issue  Is  one  which  is  still  being  researched  today. 
Presently  there  is  no  standardized  methodology  for  vendors  who  produce  CASE 
tools  involving  requirements  traceability.  There  is  some  research  going  on  in 
the  areas  of  traceability  and  the  capturing  of  design  decisions. 

The  Naval  Postgraduate  School  is  currently  looking  at  a  conceptual  model 
and  prototype  for  formally  capturing  design  decisions.  This  model  allows  the 
designer  of  the  system  to  formally  capture  and  analyze  the  arguments  and 
assumptions  which  lead  to  design  decisions.  This  procedure  may  be  tailorable 
to  capture  requirements  traceability  across  large,  complex  systems. 

The  area  of  requirements  traceability  has  been  researched  by  commercial 
vendors  (e.g..  Cadre's  Teamwork/RQT  and  Ascent  Logic's  RDD-lOO)  and  there  are 
some  CASE  Tools  on  the  market  with  requirements  traceability  capabilities. 
These  tools  allow  for  a  simple  linking  of  requirements  to  other  requirements 
and  design  elements.  These  tools  hold  some  information  about  the  links  using 
keywords  and  attributes.  The  linking  techniques  are  very  informal  in  nature 
and  do  not  allow  for  any  automatic  consistency  or  correctness  checking  of  the 
requirements  to  design  links. 

The  idea  of  complex  linking  is  one  of  the  most  challenging  to  Implement. 
One  of  the  most  complicated  parts  of  this  effort  is  determining  exactly  what 
type  of  formal  information  needs  to  be  captured  concerning  how  requirements 
link  to  the  design  elements.  This  involves  capturing  both  the  engineering 
knowledge  concerning  the  design  and  what  specific  types  of  relationships  exist 
between  requirements  and  the  design  elements .  Once  this  Information  is 
discovered,  creating  a  nomenclature  for  capturing  this  combination  of 
knowledge  and  relationships  can  be  developed. 
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CHAPTER  5 
FUTURE  PLANS 


The  Requirements  Specification  and  Traceability  Task's  plans  include  the 
continuation  of  research  in  both  the  specification  and  traceability  areas. 

All  the  Information  compiled  will  be  documented  in  two  Technical  Reports 
Methodolo^  for  System  Specification  and  Traceability  of  Large  Complex  Real- 
Time  Systems  (updated)  and  Design  View  Traceability  Techntoues^ .  The 
following  paragraphs  describe  in  some  detail  the  future  plans  of  this  research 
effort. 

A  full  evaluation  of  several  requirements  specification  languages  will 
be  performed.  Based  on  this  evaluation,  one  or  more  specification  languages 
will  be  chosen  to  be  Included  in  the  formal  structure  for  the  RESPECT 
methodology.  The  beginnings  of  the  notation  for  combining  these  specification 
languages  and  methods  for  consistency  checking  between  these  languages  will 
also  be  developed. 

A  detailed  investigation  into  the  types  of  information  that  need  to  be 
captured  by  complex  linking  techniques  (l.e.,  what  information  is  important  in 
linking  requirements  to  design)  will  be  performed.  This  will  include  defining 
the  proper  questions  to  ask  the  domain  experts,  who  presently  specify 
requirements,  and  system  designers,  followed  by  a  report  of  their  answers. 

The  research  effort  will  look  at  the  Naval  Postgraduate  School's 
conceptual  model  of  capturing  design  decisions.”  The  emphasis  will  be  on 
improving  it  to  effectively  capture  large,  real-time  complex  systems.  This 
will  include  capturing  design  decisions  through  all  design  phases  and 
consistency  checking  and  validation. 

The  research  effort  will  start  to  develop  complex  linking  techniques 
based  on  the  needs  of  the  domain  experts.  These  techniques  will  capture  the 
information  that  the  Naval  Postgraduate  School's  work  does  not  cover. 

This  research  effort  will  look  at  how  existing  commercial  traceability 
tools  can  fit  into  the  RESPECT  methodology.  The  tools  that  will  be  examined 
include,  but  are  not  limited  to,  Teamwork/Rqt,  R-Trace  and  RDD-100. 

A  mock-up  demonstration  of  an  interactive  entry  environment  for 
requirements  specification  will  be  developed.  This  environment  will  be  used 
for  demonstration  purposes  using  entry  into  an  Information  Modelling  (IM) 
method.  The  IM  method  is  one  of  the  main  views  used  in  design  capture,  and 
the  method  is  also  applicable  to  requirements  capture. 
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EVALUATION  CRITERIA  FOR  REAL-TIME  SPECIFICATION  LANGUAGES 


1.  Introduction 

This  report  proixses  a  set  of  evaluation  criteria  for  languages  designed  to  specify  the 
requirements  of  real-time  systems.  It  is  intended  for  a  reader  who  is  beginning  a  real-time 
development  project  and  considering  a  method  or  language  for  capturing  the  system’s 
requirements.  We  assume  the  reader  is  familiar  with  at  least  some  real-time  specification 
languages  and  with  the  characteristics  that  distinguish  real-time  systems  from  others. 
Specification  languages,  for  the  purpose  of  this  study,  include  Ixith  highly  formal  languages 
(having  at  least  a  formal  syntax)  as  well  as  informal  ones.  We  include  technical  criteria  we 
believe  may  be  formally  evaluated,  such  as  the  ability  to  verify  timing  properties;  we  also 
include  criteria  of  a  more  subjective  nature,  such  as  readability  and  ease  of  use.  For  each  we 
include  a  list  of  key  questions  that  a  developer  may  use  to  help  evaluate  a  candidate 
lamguage. 

Not  surprisingly,  the  criteria  are  not  unrelated,  although  how  they  affect  each  other 
varies  from  case  to  case.  For  example,  increasing  the  formality  of  a  language  may  increase  or 
decrease  the  readability  of  the  specification.  A  language  with  a  strong  conceptual  construct 
and  high  applicability  to  real-time  systems  probably  produces  a  very  concise  specification, 
which  may  be  easier  to  modify,  but  an  overly  concise  specification  (or  an  overly  verbose  one) 
may  have  very  poor  readability. 

We  do  not  provide  value  rankings  for  the  criteria,  because  the  value  varies  with  pro¬ 
jects.  For  example,  ease  of  learning  would  be  more  important  to  a  project  staffed  with 
unskilled  or  inexperienced  personnel  than  one  with  seasoned  veterans;  sophisticated  support 
tools  may  be  irrelevant  to  a  project  without  the  computing  resources  to  exploit  them. 

We  do  not  at  this  time  provide  objective  measurement  procedures  for  the  criteria.  For 
some  criteria,  derivation  of  measurements  represents  an  obvious  continuation  of  this  work 
and  is  beyond  the  scope  of  the  current  effort.  For  others,  it  isn’t  clear  that  finding  an  objec¬ 
tive  measure  is  feasible.  In  any  case,  we  believe  that  the  identification  of  the  criteria  is  useful 
in  its  own  right.  It  should  motivate  the  project  manager  to  think  about  long-term  issues  and 
provide  a  justification  framework  for  choosing  a  particular  language  and  rejecting  others. 

The  evaluation  criteria  are  presented  in  two  sections.  Section  2  suggests  language 
features  that  support  desirable  properties  of  the  finished  product — the  requirements 
specification.  Section  3  proposes  language  features  that  facilitate  the  process  by  which  the 
specification  is  produced.  A  brief  summary  appears  in  Section  4.  A  bibliography  and  glos¬ 
sary  relevant  to  real-time  system  specification  conclude  this  report. 

2.  Product-Oriented  Criteria 

The  product  under  consideration  is  the  requirements  specification.  The  purpose  of  a 
requirements  specification  language  is  to  establish  a  syntactic  and  semantic  context  in  which 
to  develop  that  product.  The  purpose  of  a  requirements  specification  b  to  define  all  accept¬ 
able  implementations  of  a  system  and  to  specify  any  constraints  on  its  implementation  [Heit- 
meyer  and  McLean  1983].  We  take  as  axiomatic  that  a  requirements  specification  should  be 
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unambiguous,  complete,  verifiable,  consistent,  easy  to  change,  traceable,  and  usable  during 
development,  operation,  and  maintenance  [ANSI/IEEE  Std  830-1984].  A  specification 
language  must  at  least  permit  such  properties  in  a  requirements  specification.  It  might 
guarantee  them  (by  making  it  impossible  to  produce  a  product  without  them);  it  might  sim¬ 
ply  encourage  them  (by  providing  features  designed  to  ease  their  rendering).  Note  that  a 
language  that  guarantees  a  good  product  need  not  be  the  best  choice;  it  might,  for  instance, 
be  prohibitively  hard  to  use. 

In  the  following  subsections,  we  suggest  evaluation  criteria  related  to  the  production  of 
high-quality  requirements  specifications  in  the  context  of  real-time  systems. 


2.1.  Applicability  to  Real-Time  Systems 

Since  real-time  systems,  by  definition,  must  respond  to  events  under  some  timing  con¬ 
straints,  it  is  imperative  that  the  language  for  rendering  real-time  specifications  be  able  to 
express  such  timing  requirements.  The  existence  of  a  model  for  timing  in  the  requirements 
specification  language,  and  the  notation  for  expressing  timing  constraints  is  the  primary  issue 
that  sets  real-time  and  non-real-time  specification  languages  apart.  The  timing  model  may 
be  based  upon  either  continuous  or  discrete  time.  Furthermore,  soft  real-time  systems  deal 
with  stochastic  performance  models;  their  requirements  are  written  in  terms  of  a  some 
minimum  number  of  times  that  a  real-time  deadline  must  be  met.  By  contrast,  hard  real¬ 
time  systems  use  deterministic  models;  their  minimum  required  rate  for  satisfying  a  deadline 
is  100%.  Some  systems,  such  as  the  Space  Shuttle,  combine  aspects  of  both  soft  and  hard 
real-time:  a  set  of  primary  or  high-priority  tasks  must  always  meet  their  deadlines,  whereas 
it  is  permissible  for  less  important  tasks  to  fail  to  complete  from  time  to  time. 

It  is  not  sufficient  that  requirements  for  real-time  systems  express  only  an  ordering  of 
events,  system  responses,  etc.;  they  must  also  express  absolute  and  relative  time  intervab 
from  a  fixed  starting  point.  Timing  constraints  should  be  stated  only  in  terms  of  events  that 
are  externally  visible  at  the  system  level.  To  achieve  this  goal  the  model  of  the  system 
environment  embraced  by  the  language  must  be  complete  and  well-defined. 

Some  specification  languages  suitable  for  real-time  systems  may  have  semantics  for 
parallelism,  which  some  real-time  applications  may  need.  The  semantics  of  parallelism  in  the 
specification  language  may  use  either  a  maximal  pardlelism  model  or  an  interleaving  model. 
Maximal  parallelism  allows  any  number  of  events  to  occur  simultaneously,  as  in  the  real 
world.  The  interleaving  model,  on  the  other  hand,  forces  simultaneous  events  to  be  sequen- 
tialized  artificially.  Interleaving  is  considered  inadequate  by  some  for  handling  certain  situa¬ 
tions  involving  simultaneity  in  a  meaningful  manner  [Mok  1991).  Others  find  that  it  is  possi¬ 
ble  to  incorporate  time  into  an  interleaving  model  to  represent  real-time  adequately  [Ostroff 
1989j. 

Key  questions  about  the  applicability  of  the  language  to  real-time  systems,  then, 
include: 

(1)  Can  the  language  express  absolute  and  relative  timing  constraints? 

(2)  Is  the  language’s  model  of  time  discrete  or  continuous? 

(3)  Can  timing  constraints  be  expressed  only  in  terms  of  events  observable  to  the  system  in 

its  operating  environment? 
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(4)  Can  the  language  express  stochastic  requirements  for  deadline  satisfaction? 

(5)  Can  the  language  express  what  is  required  to  occur  if  a  timing  constraint  is  missed? 

(6)  Can  the  language  express  parallelism?  Does  it  use  the  true  or  interleaved  model  of 
parallelism? 

2.2.  Representing  the  Conceptual  Construct 

A  major  concern  in  representing  a  set  of  requirements  is  capturing  the  essential  proper¬ 
ties  or  conceptual  construct  [Brooks  1987]  of  a  system  while  leaving  unspecified  those  detaib 
that  do  not  affect  validity.  The  specification  should  serve  as  an  abstraction  representing 
exactly  the  set  of  all  valid  implementations,  and  neither  overspecify  (provide  details  that  are 
not  requirements)  nor  underspecify  (omit  details  that  are  requirements).  A  specification 
should  say  what  is  required  of  the  system  and  not  how  that  system  is  implemented,  i.e.,  it 
should  represent  a  “black  box’’  with  only  the  externally  observable  behavior  specified  [Parnas 
1979). 

A  difRculty  in  representing  the  conceptual  construct  is  that  inessential  artifacts  of  a 
specification  may  be  misconstrued  as  part  of  the  conceptual  construct.  Such  is  often  the  case 
with  specifications  that  use  operational  definitions  whose  details  may  be  misinterpreted  as 
design  or  implementation  constraints.  For  example,  a  specification  may  include  parallelism 
as  a  conceptual  construct,  but  it  would  be  a  premature  design-level  decision  to  interpret  this 
as  requiring  either  a  parallel  system  or  a  distributed  system  architecture  (unless  mandated  as 
a  constraint).  Also  undesirable  are  specification  languages  that  use  design-level  concepts  such 
as  data  flow  models,  because  the  specifications  resulting  from  such  techniques  usually  imply 
that  a  particular  component  architecture  b  required.  Even  though  the  ideal  conceptual  con¬ 
struct  for  a  system  can  at  best  be  subjectively  evaluated,  it  b  desirable  that  a  specification 
language  support  modeb  and  notations  that  minimize  confusion  about  which  constructs  are 
required  properties  (i.e.,  external  behavior)  and  which  are  artifacts  of  the  specification. 

Legitimate  design  and  implementation  constraints,  which  tend  to  decrease  the  number 
of  potentially  valid  implementations  by  limiting  choices  for  designers  and  implementors,  must 
be  handled  with  care.  Different  notations  may  be  appropriate  for  such  constraints,  since  it  b 
important  that  true  constraints  not  be  confused  with  similar  appearing  constructs  that  are 
only  artifacts  of  the  specification. 

Families  of  systems  arise  anytime  when  a  requirements  si>ecification  leaves  a  choice 
open  to  the  designer  or  implementor.  WTiile  implicit  choices  left  to  the  designer  or  imple¬ 
mentor  give  rise  to  families  of  different  implementations,  we  emphasize  explicit  requirements 
constructs  that  provide  additional  family  concepts: 

•  Nondeterminbm  allows  for  different  choices  based  upon  alternate  behaviors  that  arc 
equally  suitable. 

•  Abstract  input  or  output  devices  define  families  of  systems  with  common  functionality 
but  choice  of  hardware  devices. 

•  Generic  system  parameters  (analogous  to  those  of  the  Ada  programming  language)  give 
rise  to  families  of  systems  that  differ  in  the  values  of  those  system  parameters. 

Such  concepts  in  a  specification  tend  to  increase  the  number  of  potentially  valid  implementar 
tions  and  may  make  a  specification  reusable  or  more  easily  modified.  Language  support  for 
families  of  systems  should  be  flexible  enough  to  include  the  full  range  from  nu'rowly  defined 
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single  systems  with  many  constraints  to  general  families  of  systems. 

Part  of  a  system’s  conceptual  construct  is  its  operating  environment.  Developing  a 
real-time  system  may  require  extensive  modeling  of  the  external  environment  (such  as  a  tim¬ 
ing  model  for  it)  in  order  to  describe  or  analyze  the  requirements  properly.  For  further  dis¬ 
cussion  of  this  concern  see  [Heitmeyer  and  McLean  1983]. 

Key  questions  about  capturing  a  system’s  conceptual  construct,  then,  include; 

(1)  Does  the  language  lend  itself  to  specifying  only  what  is  required,  or  is  it  burdened  by 
the  need  to  include  irrelevant  details  or  other  artifacts  of  using  that  language  in  the 
specification? 

(2)  Does  the  language  facilitate  the  representation  of  program  families  by  allowing  abstrac¬ 
tion  of  parameter  values,  hardware  devices,  and  nondeterminism? 

(3)  Does  the  language  provide  for  modeling  the  sj'stem’s  operating  environment? 

2.3.  Formality 

As  with  many  of  these  criteria,  formality  is  a  spectrum  quality  rather  than  an  absolute. 
A  formal  specification  language  has  at  least  a  precise,  rigorously  defined  syntax.  That  means 
that  it  is  possible  to  test  unambiguously  whether  a  specification  is  a  member  of  the  language 
or  not.  In  addition,  some  formal  languages  have  precisely  defined  semantics.  A  specification 
written  in  such  a  language  has  mathematical  properties  that  can  be  analyzed.  More  to  the 
point,  it  can  be  shown  that  any  system  that  meets  that  specification  will  have  certain  proper¬ 
ties.  For  example,  desired  invariants  can  be  derived  for  most  real-time  systems;  an  example 
invariant  is  “the  valve  will  always  be  closed  within  two  seconds  of  detection  of  sensor  tem¬ 
perature  exceeding  212  degrees.”  Proving  that  desired  invariants  are  implied  by  the 
specification  is  an  indispensable  exercise  in  making  sure  that  the  specification  is  valid. 

Formal  specifications  also  have  the  potential  to  be  processed  mechanically;  for  example, 
a  correctness  proof  can  be  checked  automatically,  even  if  the  proof  could  not  be  automati¬ 
cally  derived  [Liskov  and  Berzins  1979].  Completeness  and  consistency  checks  can  be 
automated  because  there  is  a  formal  definition  of  both.  By  contrast,  natural  language 
specifications  can  be  processed  mechanically  only  at  the  most  superficial  levels,  such  as  sim¬ 
ply  manipulating  various  blocks  of  text.  However,  the  role  of  natural  language  commentary 
should  not  be  overlooked  for  clarifying  the  major  points  of  a  formal  specification  or  providing 
background  and  motivation  for  the  decisions  embodied  by  the  formalisms. 

Formal  specification  languages  can  be  judged  by  the  ease  with  which  their  specifications 
can  be  checked  for  a  range  of  properties.  These  properties  include  completeness,  consistency, 
lack  of  ambiguity,  and  verifiability,  each  of  which  is  discussed  below. 


2.3.1.  Completeness 

A  requirements  specification  is  complete  if  it  has  all  the  information  needed  to  define  at 
least  one  system  that  is  acceptable  to  the  customer.  This  also  includes  support  for  any  attri¬ 
butes  that  contribute  to  completeness,  such  as  robustness — the  ability  to  handle  any  possible 
input  conditions  including  errors. 

The  specification  language  must  tolerate  incompleteness  in  a  given  requirements 
specification  during  development,  although  the  language  must  also  aid  in  detecting 
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incompleteness  so  that  it  can  eventually  be  eliminated.  Certain  constructs  are  needed,  such 
as  TBD’s,  that  allow  for  reasonable  analysis  of  an  incomplete  specification. 

Key  questions: 

(1)  Does  the  language  include  rules  that  define  what  a  complete  requirements  specification 
is? 

(2)  Does  the  language  tolerate  incompleteness  during  development? 

(3)  Does  the  language  facilitate  rapid  identification  of  areas  of  incompleteness  in  the 
specification? 

2.3.2.  Consistency 

Consistency  means  that  no  contradiction  can  be  derived  from  a  set  of  facts.  Incon¬ 
sistent  requirements  specifications  have  no  systems  that  satisfy  all  the  requirements.  A 
requirements  specification  must  be  internally  consistent;  that  is,  no  contradiction  can  be 
deduced  from  within  the  specification.  Specification  languages  should  provide  some  form  of 
internal  consistency  checking.  A  requirements  specification  must  also  be  externally  con¬ 
sistent  with  other  products  of  development,  such  as  the  design,  implementation,  etc.  Tracear 
bility  (see  Section  3.3.)  can  provide  some  support  for  external  consistency  checking. 

If  formal  reasoning  is  associated  with  a  specification  language,  then  it  is  desirable  that 
the  underlying  formal  logic  system  have  been  shown  to  be  sound.  That  is,  any  theorem 
derived  from  the  specification  must  be  true  in  the  specification  model.  Although  first  order 
predicate  logic  is  sound,  special-purpose  logics  need  to  be  shown  to  be  sound  also  (Berg  et  al. 
1982].  Formal  reasoning  is  necessary  to  precisely  define  and  to  automate  consistency  check¬ 
ing. 

Key  questions; 

(1)  Does  the  language  contains  rules  from  which  mechanical  self-consistency  checks  can  be 
derived? 

(2)  Does  the  language  provide  a  means  to  perform  external  consistency  checks  with  other 
products  of  the  development? 

2.3.3.  Lack  of  Ambiguity 

Ambiguity  in  a  specification  leads  to  more  than  one  meaning,  when  only  one  is 
intended.  A  specification  language  should  not  have  ambiguity  at  either  the  syntactic  or 
semantic  levels.  Formal  syntax  and  formal  semantics  are  solutions,  since  formal  constructs 
usually  have  unambiguous  definitions.  However,  even  the  lack  of  ambiguity  found  in  formal 
specifications  may  not  prevent  misunderstandings,  if  the  reader  does  not  have  the  appropri¬ 
ate  background  and  experience  in  the  language  [Parnas  1979). 

Key  questions: 

(1)  Does  the  language  have  a  formal  syntax  by  which  syntactic  correctness  of  a 
specification  can  be  unambiguously  judged? 

(2)  Is  the  language  semantically  ambiguous? 
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2.3.4.  Verifiability 

The  quality  of  verifiability  refers  to  the  ability  to  prove  that  some  set  of  properties 
holds  for  a  given  specification.  The  ability  to  verify  properties  of  a  specification  is  one  of  the 
most  important  reasons  for  using  formal  specification  languages. 

Specification  languages  that  can  be  verified  are  usually  built  upon  some  type  of  logic. 
To  make  verification  feasible,  it  must  be  automated.  Complete  automation  of  verification 
requires  a  decidable  language,  i.e.,  one  whose  underlying  logic  is  decidable.  Decidable 
languages,  however,  may  not  be  able  to  express  all  desired  requirements  concepts  that  could 
be  expressed  via  an  undecidable  language.  A  compromise  using  some  restricted  subset  of  an 
undecidable  language  is  generally  sought  in  order  to  provide  the  requisite  expressiveness. 
The  ultimate  goal  is  to  provide  an  efficient  automation  of  proofs,  so  that  specifiers  and 
verifiers  need  not  be  experts  in  proof  techniques. 

Key  questions; 

(1)  Does  the  language  have  a  formal  semantics  that  will  allow  proofs  of  invariant  correct¬ 
ness? 

(2)  Is  the  language  based  on  a  logic  that  has  been  shown  to  be  decidable? 

(3)  What  is  the  computational  complexity  of  the  automatic  proof  techniques,  if  any  are 

provided? 

2.4.  Constructibility,  Expressiveness,  and  Conciseness 

A  language  b  said  to  be  constructible  if  it  is  able  to  express  application  domain  con¬ 
cepts.  A  special  case  of  constructibility  for  real-time  systems  was  discussed  in  Section  2.1. 
Other  concepts  may  include  special  language  constructs  for  vehicle  position  and  attitude, 
chemical  reactions,  fluid  dynamics  quantities,  etc.  The  language  is  said  to  have  high  construc¬ 
tibility  if  (1)  the  way  the  specifiers  think  about  the  problem  domain  b  reflected  in  the  avail¬ 
able  constructs  and  in  the  way  these  constructs  are  combined;  or  (2)  the  specification 
language  b  expressive.  Expressiveness  refers  to  the  ability  to  make  statements  about  many 
types  of  properties,  and  the  ability  to  describe  varied  functionality.  So,  for  example,  even  if 
a  particular  language  b  not  constructible  with  respect  to  both  avionics  and  chemical  process¬ 
ing  domains  because  it  does  not  have  built-in  concepts  specific  to  each  one,  it  may  still  be 
expressive  enough  so  that  specifiers  can  easily  build  suitable  specifications  for  both  domains 
by  using  more  general  (domain-independent)  built-in  features  of  the  language. 

Assuming  that  the  language  b  able  to  express  a  construct  at  all,  as  discussed  above, 
conciseness  refers  to  its  ability  to  express  the  construct  with  a  minimum  of  redundant  or 
irrelevant  information.  Important  features  common  to  many  real-time  systems,  e.g.,  timing 
properties,  should  be  expressible  directly  via  a  small  number  of  primitives,  rather  than 
indirectly  in  terms  of  many  primitives. 

Alternately  viewed,  conciseness  measures  the  lack  of  rejjetition  (either  actual  or  concep¬ 
tual)  necesszu^y  in  a  document.  The  expressive  primitives  are  powerful  because  they  take  the 
bulk  of  common  information  from  the  specification  and  move  it  into  the  semantics  of  the 
language.  Support  for  some  form  of  abbreviations  (such  as  macros)  can  also  aid  in  concise 
specifications  by  factoring  out  repetitive  parts  of  a  specification.  Avoiding  such  repetition 
also  promotes  consbtency  within  the  specification  by  maintaining  a  single  definition  of  a  con¬ 
cept. 
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Key  questions: 

(1)  What  features  of  tlie  language  are  specifically  relevant  to  the  problem  domain  under 
consideration? 

(2)  What  features  of  the  language  are  relevant  across  application  domains? 

(3)  To  what  degree  must  information  (whether  detailed  requirements,  conceptual  back¬ 
ground,  or  semantic  constructs)  be  repeated  in  a  siiecification  written  in  the  language 
under  consideration? 

(4)  How  compact  is  the  expression  of  information  in  the  language  under  consideration, 
compared  to  that  of  other  languages? 

2.5.  Scalability 

It  is  important  that  the  specification  language  can  handle  scaling  up  from  small,  toy 
problems  to  preduction  real-time  systems.  A  major  difficulty  in  scalability  is  that  the  com¬ 
plexity  of  large  systems  increases  nonlinearly  with  the  size  of  the  system  (Brooks  1987).  The 
best  evidence  of  language  scalability  is  the  existence  of  previous  application  of  the  language 
to  large  production-quality  real-time  systems,  along  with  documented  evaluation  of  the 
laing  iage’s  tool  and  methodology  support.  Lacking  such  a  posteriori  evidence,  the  following  a 
priori  criteria  can  be  used: 

•  The  language  should  support  vertical  decomposition  of  a  specification  from  the  top  level 
(most  abstract)  through  refinement  to  additional  more  detailed  levels.  Consistency  must 
be  maintained  among  multiple  vertical  levels  that  comprise  a  s|>ecification. 

•  At  each  level  of  the  vertical  decomposition,  there  should  be  constructs  for  partitioning 
the  specification  into  more  manageable  work  assignments  (horizontal  decomposition). 

Key  questions: 

(1)  Is  there  testimonial  evidence  of  application  of  the  language  and  its  methodology  to  pro¬ 
duction  systems? 

(2)  Does  the  language  support  vertical  or  horizontal  decomposition  of  the  system? 

2.6.  Modifiability 

Modifiability  is  the  quality  that  makes  a  specification  easy  to  change.  Requirements  for 
real-time  systems  will  likely  change  many  times  during  the  evolution  of  a  project  due  to  such 
factors  as  changing  environment  and  changing  customer  needs  under  complex  technological, 
legal,  political,  and  social  pressures  (Brooks  1987).  The  language  must  support  ease  of 
change  throughout  the  system's  evolution. 

In  general,  readability  factors,  such  as  indices  and  cross-referencing  or  their  automated 
equivalents,  contribute  to  ease  of  change.  Additionally,  structuring  to  facilitate  anticipated 
changes  may  be  beneficial.  However,  structuring  criteria  for  modifiability  may  conflict  with 
those  for  readability  and  scalability,  and  require  a  compromise. 

Key  questions: 

(1)  Does  the  language  support  browsing  facilities  (hardcopy  or  online)  that  facilitate  locat¬ 
ing  related  sections  during  modification? 
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(2)  Does  the  language  support  the  documentation  of  anticipated  changes? 

2.7.  Readability 

Readability  is  a  quality  that  enables  individuals  in  different  roles  (specifiers,  customers, 
users,  verifiers,  and  implementors)  to  understand  a  specification  without  undue  difficulty. 
Each  role  has  its  own  perspectives  and  assumptions,  and  requires  different  educational  back¬ 
grounds,  knowledge,  and  experience.  Those  portions  of  the  specification  relevant  to  each  role 
should  be  clearly  understandable  to  each  person  serving  in  that  role. 

The  structure  of  the  specification  also  affects  readability.  It  is  preferable  that  the 
specification  language  aid  in  separating  normal  processing  from  error  processing.  Including 
indices  and  cross-references  (or  online  retrieval  equivalents)  also  promotes  understanding,  as 
well  as  modifiability. 

Key  questions: 

(1)  Does  the  language  provide  for  the  needs  of  readers  in  different  roles? 

(2)  Can  specifications  be  structured  for  readability  (e.g.,  normal  vs.  error  processing)? 

(3)  Does  the  language  support  browsing  (hardcopy  or  online)? 

3.  Process-Oriented  Criteria 

Development  of  a  good  specification  requires  the’  basic  processes  of  creation, 
modification,  and  analysis.  The  process  of  creation  should  be  supported  by  a  method  that 
provides  guidance  to  the  specifier.  Analysis  of  a  specification  takes  two  basic  forms. 
Verification  (definition  1  in  Glossary)  and  testing  apply  to  properties  such  as  consistency, 
timing,  security,  and  reliability  that  are  sufficiently  formal  to  permit  objective  evaluation. 
Properties  such  as  readability,  maintainability,  and  suitability  of  the  system  to  customer 
needs  require  a  subjective  evaluation  or  validation.  Modification  and  analysis  must  normally 
be  iterated  until  there  is  agreement  with  the  customer  that  the  specification  is  satisfactory. 

At  later  stages  of  the  life  cycle,  verification  (definition  2)  and  testing  of  designs  and 
implementations  with  respect  to  the  requirements  specification  will  occur.  Traceability,  as  a 
complement  to  analysis,  provides  limited  assurance  that  all  requirements  have  been  covered 
both  during  specification  development  and  at  later  stages. 

For  building  large  real-time  systems,  automation  of  these  processes  in  terms  of  tools 
and  environment  is  an  overriding  concern,  as  the  complexity  of  such  systems  is  generally 
unmanageable  without  tool  support. 

3.1.  Method  for  Specification  Creation  and  Modification 

A  requirements  specification  language  either  implies  or  explicitl}'  provides  a  method  by 
which  the  language  is  used  to  create  and  modify  a  sijecification.  The  method  may  consist  of 
a  sequence  of  steps  (i.e.,  suggestions  of  what  to  do  next),  procedures  or  heuristics  for  execut¬ 
ing  each  step,  rules  for  evaluating  the  results,  etc.  Guidance  should  be  in  terms  of  when  to 
apply  various  constructs  of  the  language,  as  well  as  how  to  apply  these  constructs  effectively, 
especially  when  there  may  be  a  choice  of  applicable  constructs.  Finally,  the  guidance  should 
not  be  so  rigid  as  to  encumber  the  creativity  or  productivity  of  the  specifier  [STARTS  1987). 
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Ease  of  use  of  the  methocl  should  be  evaluated  and  considered.  Ideally,  the  method 
should  require  little  formal  training  and  mastery  of  few  unfamiliar  or  complicated  concepts. 
Of  course,  the  benefits  of  the  method  must  be  weighed  against  its  start-up  cost;  one  might  be 
willing  to  invest  in  a  long  training  course  if  the  method  seemed  likeiy  to  deliver  significant 
long-term  benefits.  A  valuable  characteristic  of  a  method  is  to  allow  decomp>o6ition  of  the 
specification  task  into  small  w'ork  assignments  so  that  a  team  of  specifiers  can  cooperate  and 
at  the  same  time  work  relatively  independently. 

The  maturity  of  the  method,  whether  potential,  rudimentary,  or  fully  mature,  should 
l)e  an  important  factor  in  evaluating  the  method  associated  with  a  specification  language 
[Zave  1991].  Similarly,  the  level  of  method  support,  ranging  from  no  support  for  a  “bare” 
si>ecification  language  to  a  specification  language  embedded  in  a  methodology  that  addresses 
the  entire  system  life  cycle,  should  also  be  considered.  The  specification  method  should  also 
be  compatible  with  other  methods  used  during  the  system  life  cycle. 

Key  questions: 

(1)  Is  guidance  or  heuristics  provided  for  creating  and  modifying  specifications? 

(2)  How  difficult  or  expensive  is  training  in  the  method? 

(3)  Can  the  method  support  division  of  the  specification  process  into  independent  work 
assignments? 

(4)  How  mature  is  the  method? 

(5)  How  docs  the  method  integrate  with  others  in  the  system  life  cycle? 

3.2.  Verification  and  Testing 

A  verification  technique  guarantees  that  a  specification  satisfies  some  property  for  all 
states  of  the  system,  in  contrast  to  testing,  which  can  only  show  the  satisfaction  of  that  pro¬ 
perty  for  some  states.  In  evaluating  a  specification  language,  one  should  consider  which 
verification  and  test  procedures  have  been  established,  and  the  level  of  support  via  methods 
and  tools  to  aid  in  such  analyses. 

The  primary  concern  is  verification  and  testing  techniques  that  apply  directly  to  the 
requirements  specification;  for  example,  a  formal  specification  may  lead  to  inexpensive 
automatic  test  case  generation.  Verification  or  testing  of  designs  and  implementations  versus 
a  specification  will  occur  at  later  stages  of  system  development,  e.g.,  correctness  (definition  1) 
of  an  implementation  with  respect  to  its  specification.  Verification  and  testing  techniques  at 
the  design  and  implementation  levels  should  also  be  factors  in  evaluating  a  specification 
language. 

Key  questions: 

(1)  Which  verification  and  test  procedures  are  available  at  requirements  level? 

(2)  Which  verification  and  test  techniques  are  available  during  later  design  and  implemen¬ 
tation? 


3.3.  Traceability 

Traceability  provides  for  relating  objects  at  one  stage  of  development  to  objects  at  the 
next  stage.  Tracing  between  two  development  steps  provides  two  major  forms  of  compliancy 
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checks;  (1)  coverage  of  the  former  system  by  the  latter  (eacli  former  object  corresponds  to 
one  or  more  latter  objects)  ,  and  (2)  necessity  of  the  latter  objects  (each  latter  object 
corresponds  to  one  or  more  former  objects). 

For  requirements  specification  there  are  two  important  forms  of  traceability  that 
should  be  compatible  with  a  specification  language,  with  traceability  links  both  forward  (link¬ 
ing  the  requirements  specification  to  another  work  product)  and  backward  (linking  that  work 
product  back  to  the  requirements  specification)  [Davis  1090); 

•  The  requirements  specification  language  should  provide  a  means  of  tracing  each  require¬ 
ment  to  its  manifestation  in  the  design  and  implementation  as  a  rudimentary  form  of 
verification  or  testing.  This  should  be  supplemented  by  verification  and  testing  for 
more  complete  analysis. 

•  The  requirements  specification  language  should  provide  a  means  of  tracing  each  require¬ 
ment  to  its  informal  expression  by  the  customer  as  an  aid  in  validation. 

Key  questions: 

(1)  Is  traceability  from  informal  customer  requirements  to  the  requirements  specification 
supported? 

(2)  Is  tracing  from  the  requirements  specification  to  design  or  implementation  supported? 

3.4.  Validation 

Validation  that  a  specification  satisfies  the  customer’s  needs  is  at  present  an  informal 
process  involving  the  specifier,  the  customer,  and  the  requirements  specification.  Language 
support  for  specification  properties,  such  as  readability  and  traceability,  can  help  in  this  pro¬ 
cess,  as  well  as  support  for  techniques  such  as  prototyping,  scenarios,  and  specification  execu¬ 
tion  (e.g.,  step  by  step  execution  of  a  STATEMATE  specification  that  provides  visual 
highlighting  of  the  currently  active  state  [Harel  et  al.  1990}).  Verification  or  testing  of  pro¬ 
perties,  such  as  timing  and  safety,  provide  additional  input  to  the  validation  process. 

Key  questions; 

(1)  Which  properties  (e.g.,  readability)  related  to  the  language  aid  in  validation? 

(2)  Which  techniques  (e.g.,  prototyping,  specification  execution)  related  to  the  language  aid 
in  validation? 

3.5.  Tools  and  Environment 

Manual  introduction  of  methods,  analyses,  and  traceability  can  only  provide  limited 
support.  To  scale  up  to  production  systems  ultimately  requires  well-integrated  tool  support, 
as  could  be  provided  by  a  CASE  environment,  simply  to  cope  with  the  amount  of  data  and 
its  different  uses  by  the  people  involved  in  the  requirements  specification  process. 

Various  quality  factors  will  affect  the  acceptance  of  automation  in  place  of  manual  tech¬ 
niques.  Tools  and  a  supporting  environment  must  be  cost-effective.  Tools  should  be  robust, 
easy  to  learn,  and  easy  to  use.  Furthermore,  simple  took  (such  as  syntax-checking  editors) 
may  suffice  when  the  major  concern  is  with  recording  the  specification  rather  than  extensive 
analyses  [Place  et  al.  1990). 
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Some  basic  features  of  toob  and  environments  that  should  be  integrated  with  a 
specification  language  and  its  related  method  and  analyses  include  the  following: 

•  The  environment  should  provide  a  common  repository  for  all  requirements  and  various 
useful  relationships  among  different  types  of  information.  Special-purpose  editors  (e.g., 
structured,  syntax-directed,  graphical)  should  provide  for  the  efficient  and  correct  entry 
of  requirements  data  in  multi-user  mode. 

•  Open,  non-proprietary  data  formats  and  interfaces  should  be  standardized  to  promote 
interoperability  among  toob. 

•  The  environment  should  provide  configuration  management  and  version  control  for  the 
various  work  products  of  the  requirements  process. 

•  The  organization  of  the  environment  and  the  requirements  data  should  support  various 
analysb  toob. 

Key  questions: 

(1)  Are  the  available  toob  supporting  the  language  cost-effective,  robust,  easy  to  learn,  and 
easy  to  use? 

(2)  Are  these  toob  interoperable  with  the  development  environment? 

4.  Summary 

We  have  developed  a  set  of  general  evaluation  criteria  for  real-time  requirements 
specification  languages.  These  criteria  cover  important  properties  of  a  specification  (applica¬ 
bility  to  real-time  systems,  capturing  the  conceptual  construct,  etc.)  that  should  be  supported 
by  a  specification  language,  as  well  as  techniques  for  analyzing  those  properties  (verification, 
traceability,  etc.).  These  general  criteria  are  intended  as  a  guide  to  the  development  of  more 
detailed  criteria  during  actual  evaluations  of  specification  languages. 

We  close  by  reminding  the  reader  that  choice  of  language  plays  only  a  limited  role  in 
the  success  of  a  development  effort.  Although  a  language  may  facilitate  sound  engineering 
practices,  it  is  still  incumbent  on  the  engineering  staff  and  project  management  to  enforce 
those  practices. 
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GLOSSARY 

acceptable 

Satisfying  the  customer’s  “real”  requirements  for  a  system.  The 
customer’s  requirements  may  not  be  the  same  as  those  actually 
in  the  requirements  sijecificaiio/i.  since  the  requirements 
specification  may  not  correctly  capture  the  “real”  requirements. 
Synonym  for  valid. 

al>straclioii 

The  process  and  product  of  choosing  only  certain  attributes 
from  many  that  exist  of  an  object  or  concept.  The  chosen  attri¬ 
butes  are  imjxjrtant  with  respect  to  some  goal. 

ambiguity 

Lack  of  precision  (fuzziness),  which  allows  multiple  interpreta¬ 
tions  of  a  given  aspect  of  a  specification,  at  least  one  of  which 
would  lead  to  an  unacceptable  implementation. 

analysis 

1.  Process  of  testing  or  verifying  that  a  system  has  certain  pro- 
lierties,  for  example,  those  described  in  its  requirements 
specification.  2.  Process  of  determining  if  the  requirements  in 
the  specification  are  consistent  with  the  “real”  customer  require¬ 
ments  (i.e.,  validation). 

completeness 

Quality  that  all  relevant  information  for  developing  an  accept¬ 
able  implementation  has  been  included  in  the  specifications. 

With  incomplete  specifications  it  is  possible  to  develop  at  least 
one  unacceptable  implementation. 

conceptual  construct 

The  essential  properties  of  a  specified  system.  This  represents 
what  is  needed  to  specify  the  valid  implementations  of  the 
system — no  more  (ovcrspecification)  and  no  less 
(underspecification). 

conciseness 

Compact  expression  of  a  concept. 

consistency 

1.  (Internal  consistency)  Quality  of  a  requirements  specification 
such  that  there  are  no  contradictions  or  conflicts  among  any  of 
its  parts.  2.  (External  consistency)  Quality  of  a  requirements 
specification  that  there  are  no  contradictions  or  conflicts 
between  the  specification  and  another  product  of  the  develop¬ 
ment  process. 

constraint 

Any  decision  that  limits  the  set  of  valid  implementations  of  a 
system.  These  may  be  hardware  constraints  (e.g.,  computer  X 
must  be  used),  software  constraints  (e.g.,  database  package  D 
must  be  used),  or  non-functional  pro|}erties  such  as  performance 
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and  reliability. 

correctness 

1.  Quality  of  having  consistency  between  the  requirements 
specification  and  any  of  the  other  development  products  (for 
example,  design  specification  or  the  implementation).  2.  Quality 
of  having  consistency  between  the  customer’s  “real”  require¬ 
ments  for  a  system  and  the  final  system. 

customer 

The  person(s)  who  contracts  and  pajs  for  the  development  of  a 
system.  The  customer  usually  (but  not  necessarily)  defines  the 
system  requirements  [ANSI/IEEE  Std  830-1984]. 

distributed  system 

A  system  operating  with  multiple  processors,  and  one  or  more  of 
those  processors  shares  no  common  memory  with  the  others. 

This  makes  message  passing  for  communication  a  requirement. 

environment 

1.  (External)  environment:  The  external  conditions  and  inter¬ 
faces  under  which  a  system  operates.  2.  (Software  engineering) 
environment  (SEE):  The  collection  of  computers,  support 
software,  procedures  and  facilities  that  make  the  tools  and 
methodologies  used  by  software  developers  easily  available 
(Thayer  and  Thayer  1990]. 

formal  specification 

A  formal  specification  is  one  that  has  an  effective  procedure  to 
tell  whether  a  specification  has  a  particular  property  of  interest 
(Gunter  199lj.  This  type  of  S|>ccification  tends  to  be  mathemat¬ 
ically  oriented,  and  it  requires  more  knowledge  and  experience 
than  the  informal  type  to  understand.  Informal  explanatory 
comments  may  elucidate  formal  specifications. 

formal  verification 

Verification  in  which  the  proof  could  be  recognized  mechanically 
to  be  a  proof,  regardless  of  whether  the  proof  was  developed  by 
hand  or  (partially)  automatically  generated.  (Also  see 
verification.) 

hard  real-time  system 

System  in  which  deadlines  for  critical  tasks  (e.g.,  start  or  com¬ 
pletion  times)  must  be  met  to  prevent  some  catastrophe,  or  to 
reduce  the  probability  that  a  catastrophe  would  result. 

informal  specification 

A  specification  that  is  written  largely  using  natural  language 
rather  than  formal  mathematical  notations.  The  syntax  and 
notation  may  be  lau'gely  ad  hoc,  rather  than  consistent  in  the 
manner  of  formal  sirecifications.  An  informal  specification  may 
contain  free-form  commentary  as  part  of  the  specification  itself 
(as  contrasted  to  informal  explanatory  comments  used  with  for¬ 
mal  specifications).  An  informal  specification  is  amenable  to 
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very  limited  machine  manipulation. 

informal  verification  Verification  in  which  the  proof  cannot  be  recognized  mechani¬ 

cally  to  be  a  proof.  This  type  of  verification  tends  to  be  ad  hoc 
and  to  be  expressed  in  natural  language,  or  informal  notations 
(e.g.,  ones  invented  ad  hoc,  or  mixtures  of  various  notations). 
(Also  see  verification.) 

maintenance  The  process  of  fixing  errors  encountered  in  a  system  once  it  is  in 

operational  use,  or  changing  it  to  satisfy  new  requirements. 

model  An  abstraction  that  includes  all  essential  properties  of  the  pro¬ 

cess  or  object  being  modeled,  but  does  not  include  any  irrelevant 
properties.  Relevance  is  determined  by  how  the  model  will  be 
used.  A  specification  is  a  model  of  the  system  to  be  developed. 

nondeterminism  Property  that  an  observer  cannot  tell  which  of  several  behaviors 

should  be  chosen,  since  more  than  one  is  acceptable.  It  can  be  a 
desirable  characteristic  in  a  specification.  In  addition,  however, 
repeatability  may  also  be  desired  in  some  subset  of  these  cases, 
so  that  once  a  particular  behavior  is  chosen  later  in  the  develop¬ 
ment  process,  it  may  be  a  requirement  to  use  that  one  alone 
wherever  this  nondeterministic  requirement  appears  [Parnas  and 
Wang  1989]. 

notation  The  means  of  expressing  the  structure  (i.e.,  syntax)  of  a  given 

language  unit  (e.g.,  sentences  in  English,  or  projjositions  in  logic) 
via  the  composition  of  symlxjls.  The  notation  for  expressing 
syntax  is  not  the  same  as  the  syntax. 

overspecify  1.  To  put  extra  information  into  the  specification  of  a  software  sys¬ 

tem  to  the  extent  that  it  excludes  at  least  one  acceptable  implemen¬ 
tation  (due  to  the  extra  information  being  inconsistent,  being  design 
information  not  appropriate  to  describing  the  externally  visible 
behavior,  etc.).  2.  To  put  undesirably  redundant  information  into  the 
specification  of  a  software  system  [Place  et  al.  1990]. 

parallel  system  A  system  with  multiple  processors  that  communicate  via  shared 

memory. 

precise  Well-defined.  Precision  is  a  major  requirement  for  automated  pro¬ 

cessing. 

real-time  system  Any  system  that  must  operate  under  some  form  of  timing  con¬ 

straints.  (See  soft  and  hard  real-time  systems). 
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requirements  specification 

Product  that  defines  the  acceptable  implementations  for  a  software 
system  subject  to  constraints  (which  may  include  performance, 
operating,  interface,  and  economic  constraints)  [Heitmeyer  and 
McLean  1983,  Roman  1985).  These  constraints  should  be  minimal  so 
that  no  useful  implementations  are  precluded  [Zave  and  Yeh  1981). 

semantics  The  meaning  of  a  construct  as  opjxjsed  to  its  syntax. 

simulation  Process  of  testing  important  system  properties  by  executing  a  model 

of  the  proixjsed  system.  The  model  may  have  artificial  (simulated) 
components  for  any  of  the  comj)uter  hardware,  environment,  or 
software  functionality  [Shooman  1983). 

soft  real-time  system  A  real-time  system  that  has  stochastic  (rather  than  deterministic) 
timing  constraints. 

specification  Description  of  the  essential  properties  of  an  object  (system,  software, 

program,  etc.).  Specifications  may  be  informal  or  formal. 

specification  language  Any  method  providing  the  basic  concepts  and  relations  for  expressing 
specifications.  Specification  languages  include  formal  languages  as 
well  as  less  formal  constructs. 

syntax  The  structure  of  a  construct  as  implied  by  the  rules  for  composing  it 

from  subcomiranents  (as  opposed  to  its  semantics).  The  syntax  rules 
may  manifest  themselves  through  different  notations. 

testing  Any  process  (c.g.,  regression  testing)  for  establishing  confidence  in 

the  truth  of  some  property  of  a  specification,  design,  implementation, 
etc.  by  checking  or  executing  some  subset  of  the  total  ]X)ssible  out¬ 
comes.  In  contrast  to  verification,  testing  can  never  absolutely  verify 
(definition  1)  some  property  (except  exhaustive  testing  of  all  ixissibili- 
ties). 

traceability  Identification  and  recording  of  the  links  between  requirements  and 

the  manifestation  of  those  requirements  in  other  products  of  the 
software  development  process  (informal  customer  requirements, 
design,  implementation,  test  plans,  etc.) 

underspecify  To  specify  without  enough  detail  (i.e.,  incompletely,  ambiguously, 

etc.)  such  that  the  specification  admits  at  least  one  unacceptable 
implementation  [Place  et  al.  1990). 
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Person(s)  who  interacts  directl}’  with  a  system.  Users  and  customers 
are  not  necessarily  the  same  people  {ANSI/IEEE  Std  830-1984). 

Synonym  for  acceptable. 

Process  of  determining  that  a  software  system  satisfies  the 
customer’s  needs.  “Am  1  building  the  right  product  [Boehm  1984]?” 

1.  Process  of  proving  that  a  specification  satisfies  some  property  (for 
all  situations).  2.  Process  of  determining  if  products  of  one  phase  of 
software  development  satisfy  requiremenis  of  previous  phase.  “Am  I 
building  the  product  right  [Boehm  1981]?” 
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